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(57) Abstract 

An object oriented programming 
(OOP) based messaging interface method 
for use between a client application and a 
messaging service on a computer system is 
provided. The method includes providing: 
a message class which has data members 
and member functions related to a message 
in the messaging service, a message bin 
class which has data members and member 
functions related to holding the message, 
and a message bin name class which 
has data members and member functions 
related to identifying a message bin object 
instantiated from the message bin class. 
Subsequently, a messaging interface object 
for the message is generated as an instance 
of one or more of the provided classes. 
This generated messaging interface object 
furnishes the client application with protocol 
independent access to the messaging service. 
In addition, a storage device readable by 
a computer system for implementing the 
OOP-based messaging interface method 
and an OOP-based messaging interface are 
provided. 
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AN OBJECT ORIENTED PROGRAMMING BASED MESSAGING INTERFACE SYSTEM AND METHOD 

Field Of The Invention 

5 

Tne present invention relates generally to a messaging interface 
to an electronic messaging system for a communication network. More 
particularly, the present invention relates to such a messaging interface 
as implemented in an object oriented programming based 
10 environment. 

Background of the Invention 

A variety of different messaging systems are known which are 

15 used to transfer data between different users connected to a common 

nerwork. For example, a number of electronic mail systems are used to 
exchange maii message between human users typicallv connected to 
some form of a communication network via a personal computer. Use 
of such messaging systems are increasingly used in a number of 

20 environments over a wide variety of different type of networks. 

The types of users connected to the network are also increasinglv 
adding complexity to the network. For example, one user mav be 
connected to the network via one type of computing platform while 
another user mav use a different type of computing platform. This 

25 places an increased burden on the messaging systems to handle 

messages generated using different software and hardware having 
different messaging protocols. 

Moreover, multiple network systems are being increasinglv tied 
together (e.g., the Internet), effectively forming larger networks v 

30 connecting systems using even more disparate hardware and software. 
The messaging systems may be either directly connected to the system 
using a gateway to allow messages to be routed between the different 
systems, or indirectly connected (i.e., messaging systems which 
communicate through a third system and which are not directly 

35 connected to the same third system). 

Current messaging systems are unable to efficiently handle 
messaging between the various types of user systems. As a result, the 
type of data which may be transferred must be limited to common 
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rormats (e.g., ASCII text) to be handled by the different system. The data 
to be trans rerred across such hererogeneous environments looses 
fidelity as a result of translations and transformations to the lowest 
common denominator capable or being handled bv the different 
5 systems. Proper messaging over such disparate systems is also hindered 
by different message protocols. For example, there mav be several vvavs 
to address a single recipient, adding still further complexity- to the 
system. 

In order to address the above problems, attempts have been made 

10 to provide application programs capable of operating on different user 
systems and freely exchanging messages therebetween. Such 
approaches attempt to specifically address the different types or svstems 
being used to provide messaging capabilities. Another approach is to 
standardize or limit the types of messaging systems used on a network. 

13 This, however, limits the functionality of the network and the 
messaging systems. 

Object oriented programming (OOP) has become increasingly 
used to develop complex applications. As OOP moves toward the 
mainstream of software design and development, electronic messaging 

20 systems, like e-mail, will need to be adapted to make use of the benefits 
of OOP. A need exists for these principles of OOP to be applied to a 
messaging interface of an electronic messaging system such that a set of 
OOP classes and objects for messaging interface can be provided. 

OOP is a process of developing computer software usins objects, 

23 including the steps of analyzing the problem, designing the svstem, and 
constructing the program. .An object is a software package that contains 
both data and a collection of related structures and procedures. Since it 
contains both data and a collection or structures and procedures, it can 
be visualized as a self-sufficient component that does not require other 

30 additional structures, procedures or data to perform its specific task. 
OOP, therefore, views a computer program as a collection of largelv 
autonomous components, called objects, each of which is responsible 
for a specific task. This concept of packaging data, structures, and 
procedures together in one component or module is called 

35 encapsulation. 

OOP components, in general, are reusable software modules 
which present an interface that conforms to an object model and which 
are accessed at run-time through a component integration architecture. 
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A component integration architecture is a set of architecture 
mechanisms which allow software modules in different process spaces 
to utilize each other's capabilities or functions. This is generally done bv 
assuming a common component object model on which to build the 
5 architecture. 

It is worthwhile to differentiate between an object and a class of 
objects at this point. An object is a single instance of the class of objects, 
which is often just called a class. A class of objects can be viewed as a 
blueprint, from which many objects can be formed. 
10 OOP allows the programmer to create an object that is a part of 

another object. For example, the object representing a piston engine is 
said to have a composition-relationship with the object representing a 
piston. In reality, a piston engine comprises a piston, valves and many 
other components; the fact that a piston is an element of a piston engine 
15 can be iogicaliy and semantically represented in OOP by two objects. 

OOP also allows creation or an object that "depends from" 
another object. If there are two objects, one representing a piston engine 
and the other representing a piston engine wherein the piston is made 
of ceramic, then the relationship between the two objects is not that of 
20 composition. A ceramic piston engine does not make up a piston 

engine. Rather it is merely one kind of piston engine that has one more 
limitation than the piston engine; its piston is made of ceramic. In this 
case, the object representing the ceramic piston engine is called a 
derived object and it inherits all of the aspects of the object representing 
25 the piston engine and adds further limitation or detail to it. The object 
representing the ceramic piston engine "depends from" the object 
representing the piston engine. The relationship between these objects 
is called inheritance. 

When the object or class representing the ceramic piston engine 
inherits all of the aspects of the objects representing the piston engine, it 
inherits the thermal characteristics of a standard piston defined in the 
piston engine class. However, the ceramic piston engine object 
overrides these thermal characteristics with those specific to a ceramic 
piston which are typically different from those associated with a metal 
35 piston. It skips over the original and uses new functions related to 

ceramic pistons. Different kinds of piston engines will have different 
characteristics, but may have the same underlying functions associates 
with it (e.g., how many pistons in the engine, ignition sequences, 
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lubrication, etc.}. To access each of these functions in any piston engine 
object, a programmer would cail the same functions with the same 
names, but each type of piston engine may have different /overriding 
implementations of functions behind the same name. This abilitv to 
5 hide different implementations of a function behind the same name is 
called polymorphism and it greatly simplifies communication among 
objects. 

With the concepts of composition-relationship, encapsulation, 
inheritance and polymorphism, an object can represent just about 
10 anything in the real world. In fact, our logical perception of the reality 
is the only limit on determining the kinds of things that can become 
objects in object-oriented software. Some typical categories are as 
follows: 

• Objects can represent physical objects, such as automobiles in a traffic- 
tlow simulation, electrical components in a circuit- design program, 
countries in an economics model, or aircraft in an air-traffic-control 
system. 

• Objects can represent elements of the computer-user environment 
such as windows, menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or a 
table of the latitudes and longitudes of cities. 

• .An object can represent user-defined data types such as time, angles, 
and complex numbers, or point on the plane. 



15 



20 



25 



30 



With this enormous capability or an object to represent just about 
any iogicaily separable matters, OOP allows the software developer to 
design and implement a computer program that is a model of some 
aspects of reality, whether that reality is a physical entity, a process, a 
system, or a composition of matter. Since the object can represent 
anything, the software developer can create an object which can be used 
as a component in a larger software project in the future. 

If 90% of a new OOP software program consists of proven, 
existing components made from preexisting reusable objects, then only 
the remaining 10% of the new software project has to be written and 
35 tested from scratch. Since 90% already came from an inventory of 

extensively tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, OOP enables 
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software deveiopers to build objects out or other, previously built, 
objects. 

This process closely resembles complex machinery being built out 
or assemblies and sub-assemblies. OOP technology, therefore, makes 
5 software engineering more like hardware engineering in that software 
is built from existing components, which are available to the developer 
as objects. All this adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fully support the OOP 

10 principles, such as encapsulation, inheritance, polymorphism, and 

composition-relationship. With the advent of the C++ language, many 
commercial software developers have embraced OOP. C++ is an OOP 
language that offers a fast, machine-executable code. Furthermore, C++ 
is suitable for both commercial-application and systems-programming 

15 projects. For now, C^+ appears to be the most popular choice among 
many OOP programmers, but there is a host of other OOP languages, 
such as Smalltalk, common lisp object system (CLOS), and Eiffel. 
Additionally, OOP capabilities are being added to more traditional 
popular computer programming languages such as Pascal. 

~° The benefits of class libraries can be summarized, as follows: 

• Objects and their corresponding classes break down complex 
programming problems into many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of 
data into small, independent objects that can communicate with each 

25 other. Encapsulation protects the data in an object from accidental 

damage, but allows other objects to interact with that data bv calling 
the object s member functions and structures. 

• Subclassing and inheritance make it possible to extend and modifv 
objects through deriving new kinds of objects from the standard 

30 classes available in the system. Thus, new capabilities are created 

without having to start from scratch. 

• Polymorphism and multiple inheritance make it possible for 
different programmers to mix and match characteristics of manv 
different classes and create specialized objects that can still work with 

35 related objects in predictable wavs. 

• Class hierarchies and containment hierarchies provide a flexible 
mechanism for modeling real-world objects and the relationships 
amone them. 
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These libraries or reusable classes are useful in many situations, 
but they also have some limitations. For example: 

• Complexity. In a complex system, the class hierarchies tor related 
classes can become extremely confusing, with many dozens or even 
hundreds of classes. 

• Flow of control. A program written with the aid of class libraries is 
still responsible for the flow of control (i.e., it must control the 
interactions among ail the objects created from a particular library). 
The programmer has to decide which functions to call at what times 
for which kinds of objects. 

• Duplication of effort. Although class libraries allow programmers to 
use and reuse many small pieces of code, each programmer puts 
those pieces together in a different way. Two different programmers 

15 can use the same set of class libraries to write two programs that do 

exactly the same thing but whose internal structure (i.e.. design) may- 
be quite different, depending on hundreds of small decisions each 
programmer makes along the way. Inevitably, similar pieces of code 
end up doing similar things in slightly different ways and do not 

20 work as well together as they should. 

Class libraries provide lots of flexibility. As programs grow more 
complex, more programmers are forced to reinvent basic solutions to 
basic problems over and over again. A relatively new extension of the 
ciass library idea is to have a framework of class libraries. This 
framework is more complex and consists of significant collections of 
collaborating classes that capture both the small scale patterns and 
major mechanisms that implement the common requirements and 
design in a specific application domain. They were first developed to 
free application programmers from the chores involved in displaying 
menus, windows, dialog boxes, and other standard user interface 
elements for personal computers. 

Frameworks also represent a change in the wav programmers 
think about the interaction between the code they write and code 
35 written by others. In the early days of procedural programming, the 
programme: cailed libraries provided by the operating svstem to 
perform certain tasks, but basically the program executed down the page 
from start to finish, and the programmer was solely responsible for the 
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flow of controi. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems with a 
program that executed in just one wav. 

The development of graphical user interfaces began to turn this 
5 procedural programming arrangement inside out. These interfaces 
allow the user, rather than program logic, to drive the program and 
decide when certain actions should be performed. Todav, most personal 
computer software accomplishes this by means of an event loop which 
monitors the mouse, keyboard, and other sources of external events and 

10 calls the appropriate parts of the programmer s code according to actions 
that the user performs. The programmer no longer determines the 
order in which events occur. Instead, a program is divided into separate 
pieces that are called at unpredictable times and in an unpredictable 
order. By relinquishing control in this wav to users, the developer 

15 creates a program that is much easier to use. Nevertheless, individual 
pieces or the program written by the developer still call libraries 
provided by the operating system to accomplish certain tasks, and the 
programmer must still determine the flow of control within each piece 
after it's called by the event loop. Application code still "sits on top of" 

20 the system. 

Even event loop programs require programmers to write a lot of 
code that should not need to be written separately for everv application. 
The concept or an application rramework carries the event loop concept 
further. Instead of dealing with all the nuts and bolts of constructing 

2^ oasic menus, windows, and dialog boxes and then making these things 
all work together, programmers using application frameworks start 
with working application code and basic user interface elements in 
place. Subsequently, they build from there by replacing some of the 
generic capabilities of the framework with the specific capabilities of the 

30 intended application. 

Application frameworks reduce the total amount of code that a 
programmer has to write from scratch. However, because the 
framework is really a generic application that displays such as windows, 
supports copy and paste, and so on, the programmer can also relinquish 

35 control to a greater degree than event loop programs permit. The 

framework code takes care of almost all event handling and flow of 
control, and the programmer's code is called only when the framework 
needs it (e.g., to create or manipuiate a proprietary data structure). 
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A programmer writing a framework program not only 
relinquishes control to the user «as is also true for event loop programs) 
but also relinquishes the detailed flow of control within the program to' 
the tramework. This approach allows the creation of more complex 
systems that work together in interesting ways, as opposed to .solated 
programs, having custom code, being created over and over again for 
similar problems. 

A framework basically is a collection of cooperating classes that 
make up a reusable design solution for a g,ven problem domain It 
typically includes objects that provide default behavior (e.g., menus and 
windows), and programmers use it by inheriting some of that default 
behavior and overriding other behavior so that the framework calls 
application code at the appropriate times. 

There are three main differences between frameworks and class 
1? libraries: 

• Behavior versus protocol. Class libraries are essentially collections of 
behaviors that you can call u hen you want those individual 
behaviors in your program. A framework, on the other hand, 
provides not only behavior but also the protocol or set of rules that 
govern the ways in which behaviors can be combined, including 
rules for what a programmer is supposed to provide versus what the 
framework provides. 

• Call versus override. With a class library, the code the programmer 
writes instantiates objects and calls their member functions. Its 
possible to instantiate and call objects in the same wav with a 
framework (i.e.. to treat the framework as a class library), but to take 
full advantage of a frameworks reusable design, a programmer 
typically writes code that overrides and is called by the framework. 
The framework manages the flow of control among its objects. 
Writing a program involves dividing responsibilities among the 
various pieces of software that are called by the framework rather 
than specifying how the different pieces should work together. 

► Implementation versus design. With class libraries programmers 
reuse only implementations, whereas with frameworks they reuse 
design. A framework embodies the way a family of related programs 
or pieces of software work. It represents a generic design solution 
that can be adapted to a variety of specific problems in a given 
domain. For example, a single framework can embody the wav a user 
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interface works, even though two different user interfaces created 
with the same framework might solve quite different interface 
problems. 

5 Thus, through the development of frameworks for solutions to 

various problems and programming tasks, significant reductions in the 
design and development effort for software can be achieved. 

A more detailed description of OOP is given bv Cotter, et al, 
Inside Talieer.: Technology. Addison-Wesiey Publishing (1995). 

10 incorporation of the principles of OOP in a messaging interface 

allows the messaging system to be more tightly integrated with other 
OOP-based applications and operating systems. In addition, the 
maintenance and development effort required by such an OOP-based 
messaging interface will likely be significantly less than complex 

15 procedural programming-based messaging interfaces. This is because 
parts (i.e., objects or classes) of the OOP-based messaging interface may 
be modified as needed and automatically propagated throughout the 
software code without affecting the rest of the messaging interface. In 
contrast, an entire procedural programming-based messaging interface, 

20 as conventionally produced, must be completely tested and debugged 
each time any modification is made to the software code, because each 
modification must be manually propagated to different parts of the 
software code. 

The present invention provides a solution to these and other 
25 problems, and offers other advantages over the prior art. 

Summary of the Invention 

The present invention relates to an OOP-based messaging 
30 interface between a client application and an electronic messaging 
system. 

In accordance with one aspect of the invention, a messaging 
interface between a client application and a messaging service for a 
computer system is provided. The messaging interface includes a 
35 storage device, in the computer system, which stores OOP-based classes. 
These stored classes include: a message class which has data members 
and member functions related to a message in the messaging service, a 
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message bin class which has data members and member functions 
related to holding the message, and a message bin name ciass which has 
data members and member functions related to identifying a message 
bin object instantiated from the message bin class. The messaging 
5 interface aiso includes a processor operatively coupled to the storage 
device which generates a messaging interface object for the message as 
an instance of one or more of the stored classes. This generated 
messaging interface object furnishes the client application with protocol 
independent access to the messaging service. 

10 This aspect of the invention also can be implemented as an OOP- 

based messaging interface method for use between a client application 
and a messaging service on a computer system. This method is 
performed by device-implemented steps in a series of distinct processing 
steps that can be implemented in one or more processors. A message 

15 class which has data members and member functions reiated to a 

message in the messaging service is provided. Also, a message bin class 
which has data members and member functions related to holding the 
message is provided. In addition, a message bin name class which has 
data members and member functions related to identifying a message 

20 bin object instantiated from the message bin class is provided. A 

messaging interface object for the message is generated as an instance of 
one or more of the provided classes. This messaging interface object 
furnishes the client application with protocol independent access to the 
messaeing service. 

2d These and various other features as well as advantages which 

characterize the present invention will be apparent upon reading of the 
following detailed description and review of the associated drawings. 
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Brief Description of the Drawings 



FIG. 1 is a block diagram of a personal computer svstem in 
accordance with a preferred embodiment of the present invention. 

FIG. 2 is a block diagram of a route a message might take from an 
originator to a recipient. 
3 d FIG. 3 is a block diagram showing the transport of data through a 

messaging system. 

FIG. 4 is a block diagram of a typical messaging system. 
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FIG. 5 is a block diagram or components of a preferred 
embodiment messaging system architecture. 

FIG. 6 is a block diagram or a preferred embodiment object 
orrented programming based messaging interface used in the computer 
5 svstem shown in FIG. 1. 

FIG. 7 is a block diagram of the class hierarchy for the preferred 
embodiment messaging interface. 

FIG. 8 is a block diagram of an example life-cylce of a message in 
the messaging system. 

10 FIG. 9 is a block diagram of the class hierarchy for the preferred 

embodiment message bin classes. 

FIG. 10 is a block diagram of the ciass hierarchy for the preferred 
embodiment message bin name classes. 

FIG. 11 is a block diagram of the ciass hierarchy for the preferred 
15 embodiment message classes. 

FIG. 12 is a flowchart of the preferred embodiment object oriented 
programming based messaging interface method used in the computer 
system shown in FIG. 1. 

20 Detailed Description 

The preferred embodiment of the present invention is preferably 
practiced in the context of an operating system resident on a personal 
computer such as the IBM® PS/2® or Apple© Macintosh© computer. 
A representative hardware environment is depicted in FIG. 1, which 
illustrates a typical hardware configuration of a workstation in 
accordance with the preferred embodiment having a central processing 
unit 110, such as a microprocessor, and a number of other units 
interconnected via a system bus 112. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 114, Read Only Memorv 
(ROM) 116, an I/O adapter 118 for connecting peripheral devices such as 
disk storage units 120 to the bus 112, a user interface adapter 122 for 
connecting a keyboard 124, a mouse 126. a speaker 128, a microphone 
132, and /or other user interface devices such as a touch screen (not 
35 shown) to the bus 112, communication adapter 134 for connecting the 
workstation to a communication network (e.g., a data processing 
network) and a display adapter 136 for connecting the bus 112 to a 
display device 138. The workstation typically has resident thereon an 
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operatmg system such as the IBM OS/2® operating system or the Apple 
System/ 7® operating system. 

Store and forward messaging is a class of communication 
involving asynchronous transmission and reception of data. 
5 Asynchronous communication allows message transfer even when the 
originator and the recipient are not simultaneouslv active. The term 
"messaging" sometimes will be used hereinafter for store and forward 
messaging. 

FIG. 2 is a block diagram showing a route that a message might 

10 take from an originator 200 to a recipient 204, 208. This route is not 
usually specified in the message, but is determined by the messaging 
system. The originator 200 creates the message and submits it to the 
messaging system. The message is made persistent locallv. 
The message is then forwarded to the next hop and made persistent 

15 there at the intermediate node 206. This processes of persisting and 
forwarding is repeated between the intermediate node 206 and 
recipient2 208. The message is received by the recipient. At this time, 
the message may or may not persist after this point; however, usuallv it 
does persist. A copy of the message may similarly be delivered to 

20 Recipient 1 204 through some intermediate nodes 202. 

It is important to note that messages persist (i.e., are stored), and 
that they may be forwarded several times before reaching their 
destination. If any of the intermediate links are down, the message is 
held at that hop until the next hop can be reached. This is a basic 

25 description of store and forward messaging, including: 

Store and forward messaging has manv advantages: 
o All of the nodes along the route do not have to be up 
simultaneously. 

o The originator does not need to be directly connected to the recipient. 
30 o Timing is less restricted, so translation at intermediate nodes is more 

feasible, allowing for interconnection of different messaging systems. 
° Messages are held in a persistent state and are therefore more 

immune to failures. 



Store and forward messaging also has the following drawbacks: 
Failures can occur asynchronously with respect to submission context 
forcing more complicated error reporting and status interrogation 
machinery. 
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• timing is unpredictable. 

» Gateways and translation may result in loss of data fidelity. 
» Reception is not guaranteed. 

• Error reporting generally uses messaging facilities as well, so error 
notifications may be lost. 

• Retransmission unit is usually the whole message, which can be 
quite large. 

► Intermediate hops must have persistent storage available. 

► Messages are handled by entities who are not the originator and 
recipient, opening a potential security hole in the system. 

• Since the connectivity is not direct, originators may need help in 
finding recipients, either by being explicitly told of their existence or 
by browsing some directorv. 

15 In general, messages can carry any data. In practice, as shown in 

FIG. 3. many messaging systems are restricted to carrying a text stream 
from a limited character set. This is a consequence of the fact that many 
messaging systems had their roots in facilities designed to provide 
electronic mail between human users. Electronic mail is still one of the 

20 mam clients of messaging, and many messaging services are in fact 
implemented on the remnants of old e-maii svstems. 

As a result of this, messages containing non-text data mav need to 
be encoded when sent using older messaging systems. In addition, the 
capacities of these older mail systems are based on 1960's and 1970's 

23 technology, which may limit the maximum message size (i.e., messages 
larger than this size may be truncated, dropped or bounced back). 

Because of the ability to gateway systems together, the picture of 
the messaging systems of today and the near future may be even more 
complicated. It is possible to join heterogeneous systems in manv 

30 different combinations. This is very common in today's business 

environments. For example. FIG. 4 shows a typical messaging system. 
At least three different messaging systems are depicted here. Some are 
directly connected, meaning that some form of gateway exists between 
them and that at least some messages are capable of being routed 

35 between the different systems. An example of this is QuickMail 400 and 
Internet 402. Others are indirectly connected, meaning that thev are 
directly connected to the same third system. An example is 
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Compuserve 404 and QuickMaii 400 being indirectly connected through 
Internet 402. 

Several important points to remember about heterogeneous 
environments are: 
5 • Connectivity (direct and especially indirect) of different messaging 
systems may result in loss of data fidelity due to translations and 
transformations. 

• There may be several ways to address a recipient. 

• A single workstation may participate in multiple messaging systems. 
10 • Different systems offer different services and guarantees about those 

services. Requests made of one system may not be honored by 
another. This can happen without the originator's knowledge or 
permission. 

15 The present invention provides an interface or a front end to such a 
messaging system. The interface presented in the following sections 
attempts to provide choices to clients to ensure the level of integrity and 
interoperability desired. The interface achieves the following goals: 

• The interface is protocol independent (e.g., it is not specifically 
designed for use with only the Internet or some other electronic mail 
system). 

► The interface supports any content type. 
» The interface supports property-based message filtermg. 

• The underlving framework supports multiple messaging protocols. 

• The underlying framework allows implementations of multiple 
messaging protocols to be concurrently active. 

FIG. 5 shows the components of a preferred embodiment 
messaging system architecture. The messaging interface 500 is a set of 

30 classes that client applications (e.g., E-mail 502 and Groupware 

Applications 504) use to access messaging features. The messaging 
framework 506 is a set of classes which provide the functionality 
specified by the messaging interface 500. A service provider plugs into 
the framework 506 and provides an implementation for functionality 

35 that is specific to a messaging protocol or a storage structure. Three 

service providers are shown, including: Simple Mail Transfer Protocol 
(SMTP) 508, cc:mail 510, and X.400 512. 



20 
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The messaging interface 500 communicates between a client 
application (e.g.. E-mail 402) and a messaging service for a computer 
system (e.g., a messaging framework 406). An example of how this 
messaging interface 500 might be implemented is an OOP-based 
5 environment is shown in FIG. 6. A storage device (e.g., RAM 114, ROM 
116, and /or hard disk 120) stores object oriented programming based 
classes. The basic functions which need to be embodied in classes are 
data members and member functions related to: a message in the 
messaging service, a bin for holding the message, and mechanism for 
10 identifying a message bin. These functions can be stored in one or more 
classes. In this example, each of these functions is in a different class 
(i.e., class 1. class 2, and class 3). A processor 110 retrieves classes from 
the storage device 114 and generates a messaging interface object for the 
message as an instance of the retrieved class. This generated messaging 
15 interlace object alone or in conjunction with other generated objects 

furnishes the client application with protocol independent access to the 
messaging service. By using high-level objects, communications from 
the ciient applications can be generalized for any service provider or 
communications protocol. These generalized communications are then 
20 interpreted by the underlying messaging framework and converted to a 
compatible format before sending them to the service provider (e.g., an 
Internet service provider). Similar conversions are done bv the 
messaging framework through the messaging interface in the receiving 
direction so that both directions of communication are seamless to the 
25 client applications. 

The following description is focused on the messaging interface 
classes and general design principles used in applving them. 

FIG. 7 shows the class hierarchy for the preferred embodiment 
messaging interface. The class tree consists of many abstract classes 
needed to provide clear demarcation of behaviors and concrete classes 
that client applications can directly use. The concrete classes are shown 
with bold and italic text in this and the following figures. 

Appropriate interface classes are multi-thread safe for client 
application's usage, but some classes are not. Later sections will describe 
each class in detail and specify whether or not it has thread-safety. 

Issues of ownership of a heap-allocated object can be quite 
problematic. The messaging interface classes are generallv reference- 
counted, and manipulation of objects is through the safe-pointer objects 



30 
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to memory iocations. This aesign frees messaging client applications 
from the responsibility or storage-deallocation and thus is considered 
memory safe. 

The messaging interface has many classes that act on behalf of a 
real object - in some cases persistent objects (e.g., messages, message 
boxes, etc.). The later sections will identify these classes as surrogate 
classes. The classes that stand for themselves are labeled vaiue-like. 
One important difference a client application might notice between 
surrogate and value-like classes is that an operation on a surrogate 
object may fail due to the demise of the real object backing it. For 
example, the command "get subject" operation on a message object will 
fail, if the message object instance it is referring to has been deleted. 

The objects in TMessage hierarchy are thin handles with hidden 
master objects behind them. Hence these objects are cheap to copy. 
15 Different classes in TMessage 724 hierarchy represent a message at 

different stage in its life-cycle through the messaging svstem. 
TDraftMessage 726 part of the tree represents the messages in 
construction. These messages are not yet submitted for the delivery and 
allow adding data and messaging attributes to them. 
TMessageReference 712 on the other hand represent a message that has 
been either submitted or received and hence immutable. FIG. 8 shows 
the life-cycle of a message. Also, since message classes other than 
TMessageReference 712 are used for construction only, they can not be 
copied. This means that only one copy of a particular draft message 
exists at a time thus avoiding conflicting access to same message. 

The basic concept and behavior for all the interface classes of the 
preferred embodiment are described in the following section. A simple 
basic attributes table is provided for every class. This table provides a 
quick way to find out about many basic attributes of a class. A 
30 description of these basic attributes is given in Table 1 below. 

Table 1 

ir Multi-thread-safe An instance or this ciass can be concurrently accessed bv 

more than one thread. 

Multi-instance-sate Multiple instances of this surrogate class can be 

concurrently used to access the real object. 



20 



40 Stati c-sare 



It is OK to construct an instance of this class at static 
consrrucnon time. 
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snared- memo rv-sa re 

Surrogate Value 

Allows inheritance 

Allocation 

Abstract /Concrete 
Scope or uniqueness 
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It is OK to keep an instance or this ciass in shared- 
merron- 

Describes whether an instance or this ciass is a 
surrogate tor some otner object. 

An instance ot this ciass can be subclassed. Some classes 
are designed to be used monomorprucaliv. 

Describes whether this class allows creation or 
instances on the stack or heap or both. 

Describes whether this class allows creanon of objects. 

Provided onlv for idennher classes, it defines the name- 
space within wnicn the identifier is unique. 



Incidental system functions like assignment operator, copv constructor, 
and streaming operators. 

20 The messaging system needs to keep messages in some storage 

device (e.g., a magnetic or optical disk drive, a RAM, or a floppv disk), 
message bin classes provide abstractions for different kinds of message 
storage- A message is always associated with a message bin. FIG. 9 is a 
block diagram of the ciass hierarchy lor the preferred embodiment 

25 message bin classes. 

The root of the hierarchy is an abstract mixin class, message bin 
class 700, which represents a message bin of any kind. An example of 
this class is implemented in the preferred embodiment as the 
MMessageBin ciass 700 and could be implemented in anv other generic 

30 message bin class. There are two main kinds of bins. First, there are 
bins that allow storing messages into them. Second, there are bins that 
allow retrieving messages from them. The former is represented bv the 
message store mixin class 702 and the latter is represented bv the 
message source mixin class 704. An example of these classes are 

35 implemented in the preferred embodiment as the MMessageStore class 
702 and MMessageSource class 704. Each of these could be implemented 
in any other generic message store class and message source class, 
respectively. Concrete subclasses that allow both storage and retrieval of 
messages will inherit from both mixins. The preferred embodiment 

40 messaging system provides such concrete classes. 

The message sender class provides the functionality for message 
submission and sending. An example of this class is implemented in 
the preferred embodiment as the MMessageSender class 706 and could 
be implemented in any other generic message sender class. A sender 

45 always needs a store to keep the submitted messages. In the preferred 
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embod-men,. ,o simplify Cent appHcations usage, a MMessageSender 
,06 « a MMessageS.ore 702 a s well. Similarly, receiver runcoonaltfv is 
prov.ded by message rece.ver class 708 for receding messages at a " 
_ rece,ver-address. An example of ,h,s class is implemented in me 
5 preferred embodtmen, as the MMessageReceiver class 708 and could be 
fomented in any Cher generic message rece.ver class. It also is a 
MMessageSource 704 so tha, client app,ica„ons can retrieve messages 
directly from it. 5 

10 ,. H f MMeSSa f eBin daSS 700 15 »•* <°°< of -be bin class hierarchv. 
10 1, defmes a protocol that all bin classes must support as noted in Table 7 
below. ** 



15 



20 



30 



Multi-thread-safe 


Yes 


Surroeate/Vaiue-hke 


Surroeate 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Static-safe 


No 


Allocation - stack.heac 


Heap 


Shared -memorv-sa re 


\-o 




Abstract 



MReterenceCountec 

Constants. Enumerators. Types: 

• enum 

EStatus IkAvaiiab.'e. kUnavailablel 

MemDer Funcnons: 

• ^irrual EStatus 
UetStatus 0=0 

• virruai boo! 

Contains i const TMessaeeReterence&c message] 

• virtual bool 
DeleteAil 0=0 

• virtual TCountedPointerTo<TMessapeBinName> 
GetiSiame 0 = 0 



JO 



40 



The enumerator Estatus reflects the status of a bin. In particular a 
bin may be currently unavailable (e.g. the network connection mav be 
broken). A message bin will attempt ^connection upon a function-call 
if it is unavailable. One status ,s "kAvailable" which means that a 
message bin is currently accessible. Another status is "kUnavailabie" 
which means that a message bin is currently inaccessible. 

The GetStatus function returns the status of this bin If the 
returned value is kUnavailabie, the bin is currently inaccessible. If the 
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bin is unavailable and tryReconnectlfiJnavailable is true, this call wii) 
attempt reconnection before returning the status. 

The Contains function returns a true value, if the specified 
message itself is contained within the storage represented bv the bin. 
5 Tne DeleteAll function deletes a!i messages in this bin. After 

successful completion, this function will leave the bin empty. A 
successful completion is indicated by the returned value of true. This 
runction will not delete a message that is currentlv being accessed. In 
that case, it returns a false value after deleting all other messages. 
10 The GetName function returns the message bin name for this 

bin. 

The MMessageSource class 704 is a subclass of MMessageBin 700 
that adds message retrieval protocol as noted in Table 3 below. 
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Table 3 



3as»c Attributes: 



Multi- thread -sate 


Ye* 


Surrogate ' Value- like 


Surroeate 


Multt-instance-sa/e 


Yes 


Allows inheritance 


Yes 


Static-sate 


No 


Allocanon - stack. heap 


Heao 


Sha red - memorv-sa f e 


Nc 


Abstract /Concrete 


Abstract 



Inherits From: 
MMessageBin 

Member Funcnons: 

• virtual TMessageReference 

GetAIlMessages iTCoilectionOf<TMessaeeReference> Ai 
rerumedMessagesj const = 0 

• virruai unsismed lone 
GetMessaeeCountt i const=0 

• virtual TMessageReference 

WaitForMessageAher iconst TMessageReference&e starttngPoint) = 0 

• virtual TOnlyPointerTo<TMessagelterator> 
Createiterator () const 



The GetAIlMessages function adds the message references of all 
the messages in this bin to the supplied collection. Previous contents of 
the collection are left unchanged. 
35 The GetMessageCount function returns the number of messages 

contained in this bin. 

The WaitForMessageAfter function blocks the calling thread 
until this bin has a message whose LocalCreateTime is later than the 
LocalCreateTime of startingPoint. If an invalid TMessageReference is 
40 passed then the starting LocalCreateTime is assumed to be 
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TTime::kNegativeInrinity. and the rirst message in the bin will be 
returned. 

The Createlterator creates an instance of the message iterator class 
710 to iterate over the messages in this bin. An example of this class is 
? implemented in the preferred embodiment as the TMessagelterator 
ciass 710 and could be implemented in any other generic message 
iterator class. 

The TMessagelterator class 710 provides iteration functionality 
over a collection of messages, primanlv a message source as noted in 
10 Table 4 below. 



Table 4 

Basic Attributes: 



Multi-thread-sare 


No 


Surrocate/Value-hke 


Value-like 


Multi-insrance-sate 


Ves 


Allows inheritance 


\es 


Stanc-sare 


No 


Allocation - stack. heap 


Heao 


Shared-memorv-sare 


No 


Abstract /Concrete 


Abstract 



15 Inherits From: 

None 

Member Functions: 

„ • virtual TMessageReference 

20 First i) = 0 

• virtual TMessageReference 
Next U - 0 

• virtual r\lessae;eReterence 
GetMostRecent () const = 0 

25 

The First function returns the first message in this bin. If the bin 
is empty, an invalid TMessageReference object is returned. 

The Next function returns the next message in this bin. If the bin 
is empty, an invalid TMessageReference object is returned. 
30 The GetMostRecent function returns the most recent 

TMessageReference returned by either the First or Next function. If the 
bin is empty or no calls to First or Next function have been made, an 
invalid TMessageReference object is returned. 

The MMessageReceiver ciass 708 is a subclass of MMessageSource 
3:> class 704 that can receive messages and adds protocols to get its address 
as noted in Tabie 5 below. 
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Table 



Basic Attributes 



M ulti- thread -safe 


Yes 


Surroeate /Vaiue-hke 


Surroeate 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Stanc-sare 


No 


Allocation - stack. heao 


Heao 


Shared-memorv-safe 


No 


Abstract /Concrete 


Abstract 



Inherits From: 

MMessaeeSource 

Member Functions: 

• virtual 7CountedPointerTo<TMessaeeReceiver Adriress> 
GetName -.) = () 



The GetAddress runction returns the address for this receiver. It 
may be used to send messages to this receiver. 

The MMessageStore class 702 is a subclass of MMessageBin class 
700 and adds message storing protocol as noted in Table 6 below. 



Basic Attributes 



Table 6 



Multi -thread-safe 


Yes 


Surroeate/ Vaiue-like 


Surroeate 


Multi-mstance-sate 


Yes 


Allows inheritance 


Yes 


Static-safe 


No 


Allocation - stack.heao 


Heao 


Shared -memorv-sare 


No 


Abstract / Concrete 


Abstract 



inherits From: 
MMessaeeBm 

Member Functions: 

• virtual TMessaeeReference 

Copy Into t const TMessaeeReterenceac messaeeReterence. 
bool ahowDuoiicates = raise* 



30 



The Copylnto function copies the specified message into this bin. 
If the message is contained in this bin, another copv is made if 
allowDupiicates is true. It returns a reference to the new message. If the 
message is contained in this bin and allovvDuplicates is false, then an 
invalid reference is returned. 

The MMessageSender class 706 is a subclass of MMessageStore 
class 702 and adds protocol for sending messages as noted in Table 7 
below. 
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Table 7 

Basic Attributes: 



\Iulti-thread-sare 


Ves 


Surroeate /Value-like 


Surroeate 


Multi-insrance-sare 


Ves 


Allows inheritance 


Yes 


Static-sare 


No 


Allocanon - stack.heao 


, Heap 


Shared-memorv-safe 


No 


Abstract/Concrete ! 


Abstract 



inherits From: 

MMessageStore 



Member Funcnons: 

• virtual TMessaeeReterence 

bubmit iconst TDrartMessageei message/ = 0 

• static TCountedPointerTo<MMessa?e5endei 
GetDetauJtSender () = 0 



13 



20 



25 



30 



The Submit function submits a message in draft state for delivery 
to its recipients. After this call, the message is no longer a draft message. 
The draft message, passed in as a narameter. is invalidated and a 
message reference object instantiated from a message reference class 712 
which points to the submitted message is returned. An example of this 
class is implemented in the preferred embodiment as the 
TMessageReference class 712 and could be implemented in any other 
generic message reference class. 

The GetDefauItSender function returns the default 
MMessageSender. It is primarily used to submit messages. 

The hie system message store class 714 is a concrete subclass of 
MMessageSender class 706 (which is a subclass of MMessageStore class 
702) and a subclass of MMessageSource class 704. It represents a file- 
system-based message bin. Messages are stored in a file svstem directory. 
It provides functionality for storing, accessing and sending messages as 
noted in Table 8 below. An example of this class is implemented in the 
preferred embodiment as the TFileSystemMessageStore class 714 and 
could be implemented in any other generic file system message store 
class. 
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Table 8 



Basic Attributes- 



Multi-thread-sate 


Yes 


5 u r r o ea te / V* a I u e- It k e 


Surroeate 


\lulti-insrance-sate 


Yes 


Allows inheritance 


Yes 


Stahc-sare 


No 


Allocation - stack. hear 


Hean 


Shared- memorv-sa re 


No 


Abstract /Concrete 


Concrete 



Inherits From: 

MMessaeeSender 
MMessaeeSource 



Member Functions: 
t TDirectorv 
10 GetDirectory () const 

i booi 

DeieteSelf <) 



The GetDirectory function returns the directory used for message 
15 storage, 
boo! 

The DeieteSelf function deletes all messages in this bin and, if 
successrul. deletes the bin itself. A successful completion is indicated bv 
the returned value of true. This function will not delete a message that 

20 is currently being accessed — in that case it returns false after deleting 
all other messages and the bin remains intact. If successful, subsequent 
calls to GetStatus will return kUnavailable — all other calls will result 
in a TMessageBinlinavailable exception being thrown. 

Accessing a specific instance of a message bin requires that the 

25 client be able to specify that bin. This is accomplished using a bin name. 
Once a bin name is obtained or constructed, a bin can be obtained using 
the bin name. Bin names are also used to address messages. 

The message bin name class 716 and all subclasses, shown in FIG. 
10, must be displayable everywhere. An example of this class is 

30 implemented in the preferred embodiment as the TMessageBinName 
class 716 and could be implemented in any other generic message bin 
name class. The protocol for display name is handled by the base class. 
In addition, they must be transportable everywhere. The default storage 
and streaming behavior is managed by the base class to ensure that 

35 slicing never occurs. 

An instance of the TMessageBinName class 716 identifies a 
message bin. Its primary purpose is to allow a client to access a message 
bin. A TMessageBinName class 716 supports the GetPresentationName 
and GetTextPresentation functions. The TMessageBinName class 716 
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does not slice so that all or the data of the original class as well as the 
type is preserved as noted in Table 9 beiow. 



Basic Attributes: 




Table 9 


MuJti-thread-safe 


Yes 


Surroeate /Value-like 




Multi-instance-sate 


n / a 


Allows inheritance 1 


Yes 


Static-safe 


\ ! o 


Allocation - stack. heap 


Heao 


S h a red - rr.emorv-sa r e 


No 


A bs t ra ct / C one re te 


Concrete 






Scone of uruaueness 


Global 



Inherits From: 

MReferenceCounted 



Member Functions: 

• TCountedPomterTo<MMessaeeBin> 
GetBin () const 

• void 

GetPresentanonName iTTextdc hllini const 

• void 

GetText Re present anon i'TTexti rill in By Appending. 1 const 

The GetBin function returns a counted pointer to the message 
bin. If the TMessageBinName class 716 is invalid, or the class library for 
the specified bin is not available, an exception is thrown. 

The GetPresentationName function returns the presentation 
name of the message bin. The presentation name is that which would 
be used when displaying the name of the bin to the user. 

The GetTextRepresentation function returns a text representation 
of the message bin name. Many message bins have a valid text 
representation for the bin name. This text representation is usually 
sufficient to fully specify the bin. 

An instance of the file system message store name class 714 
identifies a file system message store as noted in Table 10 below. An 
j>0 example of this class is implemented in the preferred embodiment as 
the TFileSystemMessageStoreName class 714 and could be 
implemented in any other generic file system message store name class. 
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Table 10 



Multi-threari-safe 


Yes 


Surroeate.' Value-like 


Value-like 


Mutti-instance-sare 


r. / a 


Allows inheritance 


Yes 


Static-sare 


No 


Allocation - stack.heao 


HeaD 


Shared -memorv-sa re 


No 


Abstract /Concrete 


Concrete 






Scoce of uruaueness 


Global 



30 



Inherits From: 

TMessaceBinName 

Member Functions: 

TFileSvstemMessaeeStoreName iconst TDirectorv&c directory-* 

• TCoun:edPomterTo<TFiJe5ysterruV1essa^eStore> 
GetStore () const 

• TDi recto ry 
GetDirectory () const 



The TFileSystemMessageStoreName function constructs a file 
^vstem message store over a directory. This call throws an exception if 
the directory is invalid. 

The GetStore function returns a counted pointer to a file svstem 

store. 

The GetDirectory function returns a directory used for messages 
storage. 

An instance of the TMessageReceiver Address (also known as 
MessageReceiver Address) class 718 identifies a message receiver. Its 
primary purpose is to allow a client to access a message receiver and for 
constructing a message address bundies 720 from its class tor sending 
messages as noted in Table 11 below. .An example of this class is 
implemented in the preferred embodiment as the 
TMessageAddressBundle class 720 and could be implemented in anv 
other generic message address oundle class. 
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Tabie 11 



Multi-thread-sare 


Yes 


Surrocnte/ Vaiue-ltke 


Value- like 


Multi-instance-sare 


n / a 


Allows inhenrance 


Yes 


Static-sare 


No 


Allocation - stack heao 


Heap 


Shared -memorv-sa re 


No 


Abstract/Concrete 


Concrete 






Scope or uniqueness 


Global 



TMessaeeBiniSiame 
Member Functions: 

virtual TCountedPotnterTo<MMessaceReceiver> 
uetMessageReceiver t ) const 



The GetMessageReceiver function returns a counted pointer to a 
message receiver. It throws an exceptor,, if the receiver cannot be 
constructed, or if an instance of TMessageReceiverAddress class 718 is 
invalid. 

Particular service provider classes can be subclassed rrom any of 
these prev IO uslv described classes to further enhance the functionality 
or the messaging interface 400. For example, a Internet receiver address 
class 722 can be generated by inheriting functionality from the 
TMessageReceiverAddress class 718 to add Internet addressing 
capabilities. An example of this class is implemented in the preferred 
emoodiment as the TInternetReceiver Address class 722 and could be 
implemented in any other generic mternet receiver address class. 
Similarlv. classes can be generated for other messagmg svstems such as 
X.400. 

An instance of the TIntemetReceiverAddress class 722 identifies 
an RFC -S 22 compliant mailbox address as noted in Table 12 below. 
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Table 12 



Multt-thread-sare 


No 


Surroeate/ Value-like 


Value-like 


MuUi-ir.srance-sate 


n : a 


Allows inheritance 


Yes 


Static-sare 


No 


Allocation - stack.hear 




Sha red - memorv-sa re 




Abstract/Concrete 


Concrete 






ScoDe or uniauenes* 


Global 



Inherits From: 

TMessaeeReceiver Address 

Member Functions: 

TInterr.erReceiverAddress iccnst TTextfc RFC - S 22a d dress) 
Tlnterr^ReceiverAddress (const TText& userName, const 7Text& 



hostName. const TTexU* oresentanonName = 
Ibtandarc iext::GetEmpryText()) 



• void 



OetParrs :7Text& locaiPart.TTextic domamPan* 



const 



The TlnternetReceiverAddress function constructs a 
TInternetReceiverAddress from an RFC-S22 conformant string. This 
will throw an exception, if the passed string is not a valid RFC-822 
address. 

The TInternetReceiverAddress function constructs an Internet 
address from components that can be used to form a RFC-822 
conformant string. 

The GetParts function returns local and domain parts of the RFC- 
S22 address. For a more detailed discussion of the Internet messaging 
standard and the syntax of an RFC-S22 Internet address, see Request For 
Comments 822 f RFC-822) by Dave Crocker dated August 13, 1982. 

A message class 724 represents a message. An example of this 
class is implemented in the preferred embodiment as the TMessage 
class 724 and could be implemented in any other generic message class. 
There are many kinds of messages in a messaging system. For example, 
some kinds are messages received at an address, messages sent from an 
address, and messages in construction yet to be sent. 

Various subclasses of the TMessage class 724 represent different 
kinds of messages as shown in FIG. 11. The TMessage class 724 has the 
basic functionality for all of them as noted in Table 13. 
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Table 1. 



Basic Attributes 



10 



15 



20 



Id 



30 



40 



45 



50 



Multi-tnread-sare 


No 


Surrogate/ Value- like 


Vaiue-iikc 


Muln-mstance-sare 


n/a 


Allows inheritance 


Yes 


Static-sate 


No 


Allocation - stack. heap 


HeaD 


5h a red - m emorv-sa re 


No 


Abstract /Concrete 


Concrete 



Inhents From: 
None 

Constants. Enumerators. Tvpes. 
Componentlnciex klnvalidlnde* 
An invalid Componentlndex. 
enum 

EStatus ikDrart. kPendmg. kSendmg, 
kSent, kliecetved. kFaiiedl 

enum 

Elmportance ikBulk, kNormai. klmportanti 
enum 

ESrreamFormat IkMonomorpruc. k Po I v.Vtorp hid 

lemDer Funcnons: 
booi 

IsValid i; const 
bool 

opera tor== i const TMessageac message j const 
booi 

operator!= (const TMessageac message; const 
booi 

operator > (const TMessage& message; const 
bool 

operator < iconst TMessagei message! const 
bool 

operator >= (const TVtessaeeeic message; const 
bool 

operator <= iconst TMessageti: messaee* const 

HashResult 

Hash : ) const 

booi 

IsContainedin (const MMessageBin& messageBini const 
unsigned long 

Count Ad dresses (TMessageAddressBundIe::Kjnd5et hlten const 

Componentlndex 

CountComponents () const 

Componentlndex 

DoesContainType (const TType5urrogate& componentType) const 
bool 

IsCornponentTvpe (const TTypeSurrogatedc componentType, 
Componentlndex index) const 

void 

GerComponentTvpe (TTypeSurrogate& hllzn. 

Componentlndex index j const 
ESrreamFormat 

GetComponentStrearnForrnat (Componentlndex index) const 
void 

GerSubiect (TText& fillin) const 
EStatus 

GetStatus (> const 
Elmportance 
Getimportance () const 
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• TTirr.e 
GetCresteTirr.e < ) const 

• TTime 
GetLocaiCreateTime 11 const 

• TCounredPointer To<M\lessaeeBin> 
GetBm ■ • const 

• void 
DeieteSelr 0 const 



10 The EStatus enumerator reflects the status of a message. The 

message may have a status of manv different types. For example, 
"kDraft" means that an instance of the TMessage class 724 has not vet 
been submitted for delivery. All newly created messages are in this state 
and remain in this state until the client application calls Submit or Send 

15 on it. Another status is "kPending" which means that an instance of 
the TMessage ciass 724 was submitted by the client application for 
delivery but the messaging system has not vet sent it to a messaging 
server. Another status is "kSending" which means that an instance of 
the TMessage class 724 is currently being sent to a messaging server. 

20 Another status is "kSent" which means that an instance of the 

TMessage class 724 was successfully sent to a messaging server. Another 
status is "kReceived" which means that an instance of the TMessage 
class 724 was received by the messaging system. Another status is 
"kFailed" which means that an instance of the TMessage class 724 could 

23 not be delivered. 

The Elmponance enumerator has manv values, including: 
"kBulk", "kNormai", and "krnportant". Each is an indication of the 
client application's assessment ot the importance of this message. 
"kBulk" is the least important and "klmportant" is the most. This tag 

30 (enumerator) is mutually interpreted by the messaging client 

applications, because it is not interpreted by the messaging svstem. 

The EStreamFormat enumerator preferably has two values. One 
value is "kMonomorphic ", which indicates that an instance of the 
TMessage class 724 was added using the AppendMonomorphic 

3? function, and must be retrieved using GetMonomorpic function, 

Another value is "kPolymorphic", which indicates that an instance of 
the TMessage class 724 was added using the AppendPolvmorphic 
function, and must be retrieved using the GetPolymorphic function. 

The IsValid function checks if an instance of this class is a valid 

40 message. A message created using an empty constructor and a message 
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rererence returned at the end of an iteration are invalid references. It 
returns a true, if the message is valid. Most operations on an invalid 
message will fail. Operations on a valid reference might still fail, if the 
message has been deleted or otherwise unavailable for access. 
5 The operator== and operator'^ functions check for equalitv and 

inequality, respectively, between two messages. The first returns a true 
and the second returns a false, respectively, only if both references refer 
to the same message. The other operator functions perform an ordered 
comparison check for two messages. Message order is based on the 
10 LocaiCreateTime. 

The Hash function returns a hash key for this message. 
The IsContainedln function returns a true if this message is from 
the storage represented by messageBin. 

The CountAddress function returns the number of address in 

Id this message whose kind matches filter. 

The CountComponents function returns the number of 
components in this message. The DoesContainType function 
returns the index of the first component of type described by 
componentType. It returns klnvaldlndex, if no matching type is found. 

20 The IsComponentType function returns a true if the component at 
specified index is of type described by componentType. The 
GetComponentType function returns the type of component at specified 
index in fillin. The GetComponentStreamFormat function returns the 
streaming format for component at specified index in fillin. 

25 The GetSubject function assigns the subject for this message to 

fillin. The GetStatus function returns the status of this message. The 
Getlmportance function returns the importance tag for this message. 
The GetCreateTime function returns the time in UTC (Universal 
Coordinated Time) when this message was created. The 

30 GetLocalCreateTime function returns the time in UTC (Universal 

Coordinated Time) when this message was created in the current bin. 
Will == create time unless this message was copied from another bin 
(see MMessageStore::CopyInto) in which case it is guaranteed to be >= 
create time. The GetBin function returns a counted pointer to the 

35 message bin that contains this message. 

The DeleteSelf function deletes the message referenced by this 
object. The DeleteSelf function may fail if the message is a draft 
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message and is currently being accessed. Failure typically is indicated bv 
an exception. 

The TMessageReference class 712 is a subclass or the TMessage 
class 724. It represents either a received or submitted message. A 
5 message of this kind can not be modified as noted in Table 14 below. 



Table 14 

Basic Attributes: 



Multi-thread-sare 


No 


Surrogate /Vaiue- like 


SurToeate 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Static-safe 


No 


Allocation - stack. heao 


Bith 


Shared-memorv-sate 


No 


Abstract* Concrete 


Concrete 



10 Inherits From: 

TMessage 

Constants. Enumerators. Tvpes: 
_ • enum 

15 EIntet;nrv Iklntact, kDoNotKnow 

Member Functions: 

• TTime 
GetSubmitTime ( ) const 

20 • TTime 

GetReceiveTime >) const 

• E integrity 
Getinteenty () const 

• T5Tream<St 

operator>>= (TSrreamfi* to Where i const 

• TSTreami 

opera tor <<= (TSrreamac from Where) 



The enumerator Elntegrity can have a "klntact" value, which 
means that an instance of the TMessage class 724 was received without 
any loss of data. Alternatively, a "kDoNotKnow" status means that an 
instance of the TMessage class 724 does not have enough information to 
judge its integrity. 

The GetSubmitTime function returns the time in UTC 
(Universal Coordinated Time) when this message was submitted for 
delivery. The GetReceiveTime function returns the time in UTC when 
this message was received. If the message status is not Kreived, then 
the message has never been received (probably because it is an outgoing 
message) and the time returned is TTime::kPositiveInfinitv. 

The Getlntegrity function returns the integrity with which this 
message was received. 
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The operator>>= and operator<< = runctions streams this 
message reference and not the message data to and from, respectively, a 
stream. 

The TMessage class 724 is generally useful for referring to any 
kind of a message and accessing the message data. It does not provide a 
protocol for the creation and addition of data, because not all messages 
support that behavior. For example, received messages are immutable. 
The draft message class 726 and its subclasses provide functionality for 
constructing a new message, writing data to it and sending it. An 
example of this class is implemented in the preferred embodiment as 
the TDraftMessage class 726 and could be implemented in any other 
generic draft message class. 

A message sent from an OOP-based messaging system mav travel 
through a series of messaging routers (most of which will be non-OOP- 
i? based for quite some time). A recipient for the message may be a non- 
OOP-based messaging system. In such an environment, the issues of 
integrity of a message through the delivery and its interoperabilitv with 
non-OOP-based systems needs to be clearly defined. Several subclasses 
of the TDraftMessage class 726 may be defined to support different trade- 
20 offs between data-integrity and interoperability. 

For example, the OOP-specific message class 728 guarantees the 
data-integrity when delivered to a recipient. An example of this class is 
implemented in the preferred embodiment as the 
TCommonPointMessage class 728 and could be implemented in any 
25 other generic message class. However, only an OOP-based messaging 
system (e.g., a CommonPoint™ messaging system) will be able to 
retrieve the data from an instance of the TCommonPointMessage class 
728. CommonPoint™ is a trademark of Taligent, Inc. In contrast, the 
interoperable message class 730 is interpretable by and can be sent to a 
30 non-OOP-based messaging system. It, however, does not guarantee data 
integrity. In particular, an instance of the interoperable message class 
730 may have undergone lossy transformation of message contents. An 
example of this class is implemented in the preferred embodiment as 
the TInterOperableMessage class 730 and could be implemented in any 
35 other generic interoperable message class. 

A CommonPoint™ messaging system client application will 
choose a kind of draft message based on the requirements for data 
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lntcgnty and interoperability dictated by the problem domain as noted 
in Table 15. 



Basic Attributes: 



Table 15 



10 



20 



30 



35 



40 



Mu In- thread-sate 


No 


Surroeate/ Vaiue-hke 


SurToeate 


Multi-instance-sate 


Yes 


Allows inheritance 


Yes 


Static-sate 


No 


Allocation - stack.heap 


Both 


Shared - memorv-sa re 


No 


Abstract /Concrete 


Abstract 



Inhents From: 

TMessageReference 

Constants. Enumerators. Types: 



EReplvRecipientHandling 

IkReplyToSenderOnlv.kReplyToAllRecipients) 

• enum 

ECopyRecipientHandline I kCopvNoRecipients.kCopyAl [Recipients* 

• enum 

ESubiectHandiing IkOoNotCocvSubiect. kCopvSubiecu 

• enum 

EComponentHandhr-.K (kCopyNoCornponents. kCopyAllComponentsI 

Member Functions: 

• void 

AppendAddress (const TMessageAddressBundlefc bundle) 

• void 

AppendAddress (const TCountedPointerTo<TMessaceReceiverAddress>Ai: 

address. TMessageAddressBundle::EKind = TS4essageAddressBundle::kTo) 

• void 

AppendComponent (const TMessageReterenceac rromVVhere. 
Componentindex index) 

The following enumerators control message creation behavior, 
when a draft message is created as a reply, forward, or copv of an existing 
message. 

The enumerator EReplvRecipientHandling controls recipient 
handling when creating a draft message as a reply o a message. It may- 
have a "kReplyToSenderOnly" value which uses the sender of the 
original message as a recipient. Alternatively, it may have a 
"kReplyToAHRecipients" value which uses all of the recipients of the 
original message as recipients. 

The enumerator ECopyRecipientHandling controls recipient 
handling when creating a draft message as a copy of a message. It may 
have a "kCopyNoRecipients" value which does not copy any recipients 
from the existing message. Alternatively, it may have a 
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"kCopyAllRecipients" value which cop.es ai! recipients from the 
existing message. 

The enumerator ESubjectHandling controls the subject handling 
when creating a draft message as a forward, reply or copv of a message 
o It may have a "KDoNotCopySubject" which indicates that the subject of 
the original message is not to be co pi ed to this message. Alternatively 
it may have a "kCopySubject" value which indicates that the subject of 
the original message may be copied to this message. 

The enumerator EComponentHandling controls the component 
handling when creating a draft message as a forward, replv or copy of a 
message. It may have a "kCopyNoComponents" value which indicates 
that none of the components of the original message are to be copied to 
this message. Alternatively, it may have a "kCopvAllComponents" 
value which indicates that the components of the original message mav 
12 be copied to this message. 

The function AppendAddressBundle adds an address bundle to 
the list or addresses for this draft message. It may also add an address 
bundle with the specified address and kind to the list or addresses for 
this draft message. 

The function AppendComponent copies component at index in 
message from Where to next index in this message and returns an 
address to the list of addresses for this draft message. 

The TCommonPointMessage class 728 is a concrete subclass of 
TDraftMessage class 726. This message supports multiple components 
or anv data-tvpe and styled-text as subject. It does not translate the data 
from its original form to any other as noted in Table 16. 



20 
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Table 16 



Basic Attributes: 



\iulti-thread-safe 


No 


Surroeate/ Value- like 


Surroeate 


Multi-mstance-sare 


Yes 


Allows inheritance 


Yes 


Static-safe 


No 


Allocation - stack. heao 


Both 


Shared- memorv-sate 


No 


Abstract /Concrete 


Concrete 



inherits From: 
TDr3ttMessage 



Member Functions: 

TCornm on Point Message iconst TText&c subject > 

10 TCommonPointMessace (const TText& subject, const 

TCountedPointer7o<TMessageRecejverAddress>& toAddress) 

• static TCommonPointMessage 

^ Forward (const TMessaReReference<5c sourceMessa^e, 

1 5 EComponentHandling comoonentHandlin^ ESubiectHandling 

subjectHandline, const TText& prependToSubiect = 
T5tandardText::GetEmpryTexU)) 

• static TCommonPointMessase 

Repiv iconst TMessaceReference&c sourceMessa^e, 
20 ERepiyRecipientHandling recipienrHandhnp, 

EComponentHandling comoonentHandhne. ESubiectH and ling 
subiectHandling, const TTexta: prependToSubject = 
TS:anriardText::GetEmpry7exti)) 

• stanc TCommonPointMessage 

2.D ^°pv iconst TMessaceAc source.Vlessage, ECopyRecipientHandling 

recipientHandung. EComponentHandling componentH and ling, 
ESubiectHandiing subtectH and ling, const T7ext& 
prependToSubiect = TStanaardText::GetEmptyText()) 

30 The function TCommonPointMessage allows client applications 

to create new CommonPoint™ messages with a specified subject. One 
of the constructors allows specifying an address to which this message 
should be sent. 

The function Forward creates a CommonPoint™ message as a 
35 forward of the specified message. The newiy created CommonPoint™ 
message is properly formatted as a forwarded message. Parameters 
componentHandling and subjectHandling provide clients a finer 
control of controlling various properties of the created message as 
described earlier. If prependToSubject is present, the specified text is 
40 prepended to the subject of sourceMessage to create subject for the 
returned message. 

The function Reply creates a simple message as a reply to the 
specified message. The newly created simple message is properly 
formatted as a reply message. Parameters are handled in manner 
45 similar to Forward function. 
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The function Copy creates a simple message as a copv ot" the 
specified message. Parameters are handled in manner simiiar to 
Forward function. 

The TInterOperableMessage class 730 is a concrete subciass of the 
TDraftMessage class 724. This message supports multiple components 
of any data-type and unstyied-text as subject. Upon transmission, it may 
translate the data from its original form to one appropriate for passage 
through the messaging system. Such a translation may incur loss of 
information from the data as noted in Table 17 below. 



Basic Attributes: 



Table 17 



Multi-thread-sare 


No 


Surroeate/ Value-like 


Surroeate 


Multi-ir.stance-sare 


Yes 


Allows inheritance 


Yes 


Static-sate 


No 


Allocation - stack. heao 


Both 


Sh a red -memo rv -s a re 


No 


Abstract /Concrete 


Concrete 



Inherits From: 

TDraftMessage 

Member Functions: 

TInterOperableMessage (const TTextk subject) 

TInterOperableMessage (const TText& subject, const 

TCountedPointerTo<TMessageReceiverAddress>&: toAddressi 

TInterOperableMessage (const TText& subject, const 

TCountedPointerTo<TMessaeeReceiverAddress> luAddress. const 
TStandardText& nrstComponent) 

• static TInterOperableMessage 

Forward :const TMessaeeKeferenceac sourceMessace. 

EComponentHandhnE component Hand line. ESubiectHandlmc 
subiectHar.dhng. const TText&t prepend ToSubiect - 
TStandardTex:f:CetEmpryText( )) 

• static TInterOperableMessage 

Reply (const TMessageReferencefc sourceMessace. 
EReplyRecipientHandiing recipient Handling. 
ECo'mponen t Hand hn g componen tHand ling . liSu bfectH a nd Lin g 
subiectH and ling, const TTextic prependToSubject = 
T5tandardText::GetEmpryText()) 

• static TInterOperableMessage 

Copy iconst TMessasrefc sourceMessage, ERecipientHandiing 

recimentHandfing, ECopyComponentHandkng component Handling 
ESubiectH and ling subiec'tHandling, const TTextdt 
prependToSubject = TStandardText::GetEmptvText(}) 



45 



The function TInterOperableMessage allow client applications to 
create new interoperable messages with specified subject. One of the 
constructors allows specifying an address to which this message should 
be sent. Another constructor supports the (monomorphic) addition of a 
single text component. Regardless of which constructor is used so that 
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ciient appiicanons can add additional components using the 
AppendMonomorphtc and AppendPolymorphic functions. 

The function forward creates a CommonPoint™ message as a 
forward of the specified message (sourceMessage). The newlv created 
5 CommonPoint™ message is properly formatted as a forwarded 
message- Parameters componentHandling and subjectHandling 
provide client applications a finer control of controlling various 
properties of the created message as described earlier. If 
prependToSubiect is present, the specified text is prepended to the 
10 subject or sourceMessage to create subject for the returned message. 

Tne runction Reply creates a simple message as a reply to the 
specified message. The newly created simple message is properly 
formatted as a reply message. Parameters are handled in manner 
similar to Forward function. 
1 ? The runction Copy creates a simple message as a copv of the 

specified message. Parameters are handled in manner similar to 
Forward function. 

A component inside a TDraftMessage class 726 can be any 
CommonPoint™ object. Functionality of writing a component to a 
20 message and reading one from it is provided in a type-safe way by 

template functions Add and Get. Conceptually, the components in a 
message form an indexed collection. Client applications can add 
components to a message sequentially and access a component using an 
index. Some of these functions are detailed in Table 18 below. 

Table 18 

Functions; 

• template <ciass ATvpe> Componentlndex 

Append Polymorphic fTDrartMessas>e& message, const ATvpe&r component! 
30 • template cclass AType> Componentlndex 

AppendMonomorphic (TDraftMessage&r message, const AType& component) 

• template <ciass ATvpe> void 

GetPoK morphtc iconst TMessaeefc message. TOnlvPomterTo<ATy-pe>6c 
tiilin. Componentlndex mclex) 

3d • template <class ATvr>e> void 

GetMqnom orphic (const TMessage<& message. AType& hilin. 
Componentlndex index) 

The function AddPolymorphic adds a component to a message at 
40 the next available index. The component is placed in the message bodv 
by the process of polymorphic streaming (by calling template <class 
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AType> void Flatten (const AType*.TStream&) ). It returns the index at 
which the component is placed. 

The function AddMonomorphic adds a component to a message 
at the next available index. The component is placed in the message 
body by the process or monomorphic streaming (by calling 
AType::operator»=). It returns the index at which the component is 
placed. 

The function GetPolymorphic retrieves the component in 
message at index as an object of AType. If the component in message is 
10 of different type, this function throws TTypeMismatch exception. 

The function GetMonomorphic retrieves the component in 
message at index as an object of AType. If the component in message is 
of different type, this function throws TTypeMismatch exception. 

Another class is related to message properties. This is the 
15 TMessageAddressBundle class which represents an entity to which a 
message can be sent. Since an address is needed for sending a message, 
the TMessageAddressBundle class is constructed from a message 
receiver address and related attributes as noted in Table 19 below. 
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Table 19 



Basic Attributes: 



Multi-lhreac-sare 


No 


Surrocate Value-iike 


Value-like 


Multi-instance-sate 


Yes 


Allows inheritance 


No 


Stahc-sat'e 


No 


Allocation - stack. heap 


Both 


Shared -memorv-safe 


No 


Abstract /Concrete 


Concrete 



Inherits From: 

MReferenceCounteci 

Constants. Enumerators. Types: 

• enum 

EKind IkTo. kCC kBCC. kForwardTo. krrom. kFonvardFrorn. kReolvTo 
kRecipient. kAlli 

Member Funcnons: 

T Message Ad dress Bundle (const 

TCountedPotnterTo<TMessa^eReceiverAddress>& address, EKind 
kind = klo) 

TMessaeeAd dress Bundle (TSrreanttc rrom Where 1 
TMessaeeAddressBundle (i 

• TCountedPointerTO<TMessageReceiverAddress> 
Get Address i } const 

• EKind 
GetKind i> const 

• bool 
IsValtd () const 

The enumerator EKind reflects an attribute to qualify a receiver 
30 address. These can be logically "OR'd" together to form a filter tor use 
in address iteration. One attribute is "kTo" which means a pnmarv 
target of a message. Another attribute is "kCC" which means a 
secondary target of a message. In addition, kBCC is a blind secondary 
target of a message. kJForwardTo is a forwarding target of a message. 
35 kFrom is the originator of a message. kForwardFrom is the address 
from which a message was forwarded. kReplyTo is an address used 
when replying which defaults to kFrom address. kRecipient is a 
predefined filter for (kTo + kCC -r kBCC -r kForwardTo). kAll is a 
predefined filter which will match any kind. 
■*0 The function TMessageAddressBundle constructs a bundle object 

with the specified address and kind. Alternatively, it constructs a 
bundle object by streaming data from the stream fromWhere. 
Alternatively, it creates an invalid bundle. Such a bundle is useful for 
future assignment. A null bundle in a draft message is ignored. 



10 
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The runction GetAddress returns the address ror this bundle. 
Also, the function GetKind returns the kind attribute for this bundle. 
In addition, the runction IsValid returns true if the bundle has a valid 
address. 

5 Another class related to message properties is the 

TMessageAddressIterator class (not shown) which provides an iterator 
over the addresses in a message as noted in Table 20 below. 

Table 20 

10 Ba^ic Attributes: 



Multi-thread-sate 


No 


Surroeate /Value- like 


Value-like 


Multi-mstance-sate 


Yes 


Allows inheritance 


No 


St3tic-sate 


No 


Allocation - stack. heap 


Both 


r*r.3L red- memorv-sa 10 


No 


Abstract /Concrete 


Concrete 



I rthe nts From: 
None 



15 Member Funcnons: 

TMessaeeAddresslterator i const TMessaKtir message. 
T M essage Address Bund ie::E Kind Set niter = kTo) 

20 TMessageAddressiterator 0 

• virtual TMessageAddressBundle 
First f) const = 0 

25 • vjrtuai TMessageAddressBundle 

Next t) const = 0 

• rool 

x > cerator== iconst IMessaseAddressI teratoid richt) const 

30 

• rool 

operator!^ (const TMessageAddresslterator& right) const 

The TMessageAddressIterator function creates an iterator over 
35 the specified message with the specified filter. Alternatively is may 

create an invalid iterator which can be reserved for a future assignment. 

The First function returns the first address in this message. If the 
bin is empty, an invalid TMessageAddressBundle object is returned. 

The Next function returns the next message in this bin. If the bin 
40 is emptv, an invalid TMessageAddressBundle object is returned. 

The operator== and operator!^ functions are equality (inequality) 
checks for two iterators. They return a true if both iterators refer to the 
same message, have the same filter, and have the same iteration 
'position'. 
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Some general items to note are that subclass Application 
Programming Interface (API 1 ) classes are not needed to use the 
messaging interface classes. The messaging interface API is built on top 
of a messaging framework. The framework requires subclassing of a set 
3 of classes to plug-in a service provider. 

The messaging interface API does not guarantee delivery of a 
message. Different service-providers may have different level of 
delivery guarantees. Some messages may be delivered with loss of data. 
The messaging API defines a message type that will not suffer any 
10 transformation when delivered to a CommonPoint™ recipient 

(TCommonPointMessage ciass 728). There is a type of message which 
imposes no constraints on the contents or recipients 
'TlnterOperableMessage class 730). However, the messaging interface 
API makes no guarantees about the integrity of instances of the 
15 TlnterOperableMessage class 730. 

Both TCommonPointMessage class 728 and 
TlnterOperableMessage class 730 support multiple components of any 
tvpe, as long as the type has the CommonPoint™ tvpe extensions. 
Instances (i.e.. objects) of the TlnterOperableMessage class 730 may drop 
20 the components that can not be translated appropriately. 
By iterating over component types using 
TMessagenGetComponentType. contents of a message can be 
determined. In addition, the existence of a specific type of component 
isav text) can be checked bv using TMessagenDoesContainType. 
25 The messaging interface API does not provide any direct means 

other than construction or reading of received messages for obtaining 
receiver addresses. The goai is to have receiver address manufactured 
bv other objects such as people or business cards, etc. 

Client applications mav use service-provider-specific address 
30 classes (e.g., the TlnternetReceiverAddress class 722) bearing in mind 
that it results in routing a message to that address through only given 
service-provider. 

To keep the different aspects of storage behavior separate from 
each other several bin classes are provided. For example, the 
35 MMessageStore class 702 provides writing behavior (create or copy a 
message in to) for a bin. while the MMessageSource class 704 provides 
reading behavior (iterate over contained messages). This kind of 
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separation allows tor constructing subclasses with various combinations 
ot tnese behaviors. 

This separation of behaviors ,s strictly enforced. For examoie 
- ^ IM t S5 u a§eSt ° re pr ° VideS -"te-onlv protocol to message bin. It would 

" th , Tu te " 0nly beh3VIOr ^ Pr ° Vlde Wait f ° r ° r Itera * P-tocol in 
this class. Thus, it is not possible to wait for (i.e., kev off on, a messaee 
arrival at a MMessageStore object. ' 6 

The following example shown in Table 21 illustrates the use of 
basic functionality provided by the messaging interface. 
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Table 21 

SRevision i Z i 
MessagincSarr.olesC 

Ccpyngnt £ 1995 Taiiernt. Inc. All nenrs reservrc 

In oraer to iocus on the Messaging API i. this crocr.Tm uses a rradinon^; 
C srvie wr.n a man ana ciobai runcooni 



Includes 



*imdet Taligeni MESSAGING 

*imlude < r absent/ Messaging n> 
■endir 

*imdei Taiieem. [NTERNETRrCErVE RAD DRESS 

^include «.7aucent/ lnteme»J<ecMver Address ji> 
•endu 

nrnde i Tabgen t . DOC U\! E VTSTOR ECONT E NiTSTKE AM E R 

^include <Taiieent/DocurrcnororeConrentSirearner.r.> 
■endu 

»imder Taugent.SAMPLEPROCEDUREMAPS 

"nnciuoe <Taligent/;>ampieProcedureMaps.h> 
-endii 

'imder Tabeent.EXCEPnONTORStATTF.R 

*\ncjuae <Tal:gem/ bxcepocrurormatrer h> 
*ersdi: 

nmdc Taugem M ULT IF L E ROOTLOC A TOR 

"incJude ■ T aii cenr ; MumpieRootLoca:or.n> 

»irndei Talicent BASICDCCt/MENTSTORACn 

=mc lude -:Taijcent.' Basic Doc*jmentt>torage.n> 
Jendii 



Message xncUn^ Funcaons 



' Sena a message contauunc text onlv The message can be read within almost 

anv mail svsiem on anv no*t. Text svles will be stripped and some loss or 
• text mav occur due to character set rransianon 

void SeralnrerorvraoleText -ccnsi TCountedPointerTo<TMessageKe<eiver Address>dr 
address. 

const TStanoardText^c subiec:. 
<:onst TStanaardTexi& texn 

TtnterooeracteMessage me^saeetsubiect. address. text* Make mcss^ci-. 

x vtMessaee=«noer::GetDefau:oenden i- >:?ucrruii message). Submit 



Send a message containing text oniv The message can onlv oe read within 
• CommonFoinl :v * 

void SendCommonPointText .censt TCounrtd Pointer To<TMessageReceiverAddress>& address, 
const TTex:i: iubiect. 
const T Standard Text& text) 

Note TStandardText onects should normally re handled using 

AdcLMonomorpnic and GetMonomorphuc run coons. Polymorphic handling 
is needJesslv expensive 

TCommonPointMessaee message tsubieci -addressi. / / Make message 

A ppencLM on omorphtct message. text): / Add the text. 

NLMes»eeSender^etDeiauic>ender( >->bubmit<messagei: / / Submit 



' .* Send a message containing a single CommonPoint ^ object The message can oniv 
' ' be reao w»trun CommonPctnt™ 

temoiate < class ATvre> 

void SendOneObrect iconst TCountedPomterTo<TMessageKeceiver Address > it address, 
const TTextA sunect. 
const ATyperfc onecn 

TCommonPointMessaee message tsubtec t address «. // Make message 

Append Polymorphic! message. ODieen. ■/ Add the obiect. 
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^t^tesM^»e^e^v^er:.Cc^Del ; au^C5endefO->buDmJlImessaEe). 



/ Send a messaee containing three CommonPoinr * obtects The message can onjv 
/ / be read within CornrnonPotnt 4 44 

temolare <cJass ATvpe. class BType. class CTvpe> 

void SeTidTru-eeObiects (const TC ou n tedPointe r T o< TMessa Re Receiver A dd/ess> & address 

const TStandaxdTextfc subject. 

const ATypefc object! . 
const BTvpe& ob*ect2. 
const CTvpedc obtect3) 

TCommonPoiniMessage messa get subtect -address). / / Make messaee. 

A ppend Pol vnmorpruct messaee. obrec 1 1 1: / ' Add the ooiects 

A p pend Pol vmorpruet messa ee.obiec t2 ) : 
. \ p pendPol vrnorphiet messa e e.obtec t3 ». 

NtN!essaee^nder:GetI>fauIoerKler()->SubrrutirnessaEc». SuDmit. 



.' ' Messaee fcxaminanon Functions 



/ Scan messaee and return true lit contains a component or the srecined tvpe: 

boci DoesMessaeeComain iconst TMessageReterencedi messaee. 
const TTvpeSurroeave^ tareetlvpe) 

rooJ round = raise. 

:or rir.t i = t>. i < messaee.CounrComponenisi i. »*- » 

•j i messaee. JsComnonenrrvpeitarj^rtl v-pe.ui 

round = true: 
breax. 



re rum found. 



Scan messaee and print ail text components 

v oid PnniTextComponents tconst TMes sage Referenced messaee > 

t 

TStandardlew text. 

TTvrcaurroeaie texiTvpetSrancTxpelntotTStandardText) >. 
^^m^oncniinde* count = messai?e.CountCornc>onentsi ); 

unt i -- \. : < count: i** » 

u imessaee.lsComDonentTvpertextIvpe.nl 

v>uMonomorpruclmessaee.text.i>. / / fcxtfact urxt rrom messaee. 
O Pnnt Tex ti text); //Pnntit. 



• >?na and Receive Messages 



void Messagin examples (const TCountedPointerTo<T MessaeeReceiverAddress>& address, 
const TText4t texeiubiect. 
const TStandardTextfe text Bod v 
const TTextit cpSubiect. 
const TdocurnentRererence& document, 
const TTime& tune, 
const TProceoureMapfe map) 

I 

Send an interoperable text message 
Ssndin tempera b leTcx t ( address .tex tSubtec t . tex t Bod v l; 

Send a text obiect-.. 

SendC ornmonPoin tT ex ti add ress. textSubtec t jex t Bod v >; 

Send a message c ont amine a single CommonPoint object <a document 
bv reterencei... 
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ncndOneObtec ti address, cd suoiect.documer it. 

iend a mesM«e contaimne a stncte ConimonPoint cbieci (a document 
' bv vaiuei... 

^ndCmeOticcn address. rcSub»cciT Do cumenDtoreCanrentSrrearneri do 

' Send a message containing three CommonPcint objects... 

^endThreeC'Diectsiaddiess.cpSubiect.document. rune, map p; 

/ War! ror ihe messages tc be recievec. F:rs:. get me receiver 
*'•' instance.. 

TCoun ted Pointer ro<MMessaeeReceiver> receiver = address- >CetMessage Receiver; i; 

Now iocp waione unni we reeteve the message containing 
a TProcecureMap .. 

boo I .lone s raise. 

TTvpeiorroeate rriaprypeibtancTypeinionProcedureMap)): 
TMessageReierence received Message. // S»tart with an invabd message 
while <• done. 

/ / Wait icr a new message to arrive... 

received-Message = receiver- >WaitForMessageAi ten receded Messages 

' Pnm anv text components in the messaee 

I'rtntTe^rJ.cmponentsi received Message i. 

Terminate wnen we ve rroeved the message containing tnree 
.• / obteccs. one 01 which is a document . 

ir treceived Message. Court rComponentsi > == >i 

done = DoesMessageContaint received Messaee. map Type i: 



Main 

'■ For stmDuc.rv «.ve assume that this program is entered from tne command 
line, and tr.ar it is passed a sinete argument wmch is treated as an 
Internet srv.e mau address Ail other data is nara coded. 

Norma li\ Addresses snouia be remeved trom either a business card or rrcm 
the cirecrrr* services 



int ma in iint arcc. char'argvj |i 
bool tailed = large !■ 2\ 
it t! faiied *. 

TOruvPDmterTo<TDocumenC>tore> store: 
TOnlv! J omterTo<T5tariciardStorageMechariism> mechanism. 

rrv 

/ / Make an Internet address... 

TCoun redPoinrerTo<TMessage Receiver A dd ress > address ■ 
new TlntemetKeceiverAddressiTStandardTexttargv( 1))). 

1 * Make up the remaining arguments to Messaginpsampies .. 

TSiandardText iexoub>ecM*TeTt Enclosed. ). 

TStandardTe^t text Bod v( This is a text message rrom CommoriPoin: ">, 
TSrandardText cuSubtectl CommonPoint Objects Enclosed. '»; 
TSeconas timeil234); 
TMarbleProcedureMap map. 

/ / Get a TDcxnifnentRerereTtce... 

TMulbpleRoottocator I oca torf" Places ). 

TDu-ecrcrv nomePlace - locator.FindFirstBvNameC DefauhUsrrHomePlace i. 
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TX>ucumrntKe^rmce uoaimenc r. MOrp ^.DocummtKcrcrencei). 
Now execute ine samples.. 

catch iCDnst TStandaxdExcepnon<* exception » 



faiied - true- 
TStandardText m.essaee. 

15 TE,C " n0n,:0nM "" < -' ,,:orma "^TeM IC x«pnon.TLo C a, r ..t;ert.urTeT„Locale., 

message*. 

vj Print Text i message:. 



raxleu = rrue 

OIVuMTextlTS.anaa/dTexM An unbown exccpnon w*s caupht. » 

else 

t 

OPnniText.TStanda/dTextt Invabd areuments. Use MessaemeSampjc 
address)}: ° r 

rcrurn tailed * 1 j» 



35 



The present invention can be summarized in reference to FIG. 12 
which is a flowchart of the preferred embodiment object oriented 
programming based messaging interface method for use between a 
client application and a messaging service on a computer svstem. This 
method is performed by device-implemented steps in a series of distinct 
processing steps 1200-1212 that can be implemented in one or more 
40 processors. 

A message class 724 is provided 1202 which has data members 
and member functions related to a message in the messaging service. In 
addition, a message bin class 700 is provided 1204 which has data 
members and member functions related to holding the message. Also, 
a message bin name class 716 is provided 1206 which has data members 
and member functions related to identifying a message bin object 
instantiated from the message bin class 700. Subsequently, a messaging 
interface object for the message is generated 1210 as an instance of one of 
these provided classes (i.e.. the message class 724, the message bin class 
700, or the message bin name class 716. This messaging interface object 
provides the client application with protocol independent access to the 
messaging serv ice. 

Other classes may be provided 1208 prior to the generating step 
1210 such that other messaging interface-related objects can be generated 
in the generating step 1210. For example, a message address bundle class 
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may be provided 1208 which has data members and member functions 
related to a message receiver address to which the message can be sent 
in the messaging service and related attributes of the message receiver 
address. In addition, a message address iterator class mav be provided 
5 1208 which has data members and member functions related to an 
iterator over the addresses. 

A message reference class 712 may be provided 1208 which 
inherits all of the data members and member functions defined by the " 
message ciass 724. It further defines data members and member 
10 functions related to locking the message such that the message can not 
be modified. . 

A draft message class 726 may be provided 1208 which inherits all 
of the data members and member functions defined bv the message 
class 724. It further defines data members and member functions 

15 related to data integrity and interoperability of the message. Further, an 
OOP-specific message ciass 728 may be provided 1208 which inherits all 
of the data members and member functions defined bv the draft 
message class 726. It further defines data members and member 
functions related to guaranteeing data integrity when delivering the 

20 message to an OOP-based message system. Furthermore, an 

interoperable message class 730 may be provided 1208 which inherits all 
of the data members and member functions defined bv the draft 
message class 726. It further defines data members and member 
functions related to guaranteeing data mteroperabilitv when delivering 

25 the message to a non-OOP-based message svstem. 

A message store class 702 may be provided 1208 which inherits all 
of the data members and member functions defined bv the message bin 
ciass 700. It further defines data members and member functions 
related to protocols for storing the message into a message store object 

30 instantiated from the message store class 702. Further, a message sender 
class 706 may be provided 1208 which inherits all of the data members 
and member functions defined by the message store class 702. It further 
defines data members and member functions related to protocols for 
submitting and sending the message from the client application to the 

35 messaging service. In addition, a message source class 704 mav be 
provided 1208 which inherits all of the data members and member 
functions defined by the message bin class 700. It further defines data 
members and member functions related to protocols for retrieving the 
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message from a message source object instantiated from the message 
source class 704. This allows a file system message store class 714 to be 
provided 1208 which inherits all of the data members and member 
functions defined by the message sender class 706 and the 
MMessageSource class 704. It further defines data members and 
member functions related to protocols for storing, accessing and sending 
the message where the message is stored in a file system directory in a 
storage device 120 of the computer svstem. 

A message source class 704 alone (i.e.. without the message 
sender class 706 and the message source class 704) may be provided 1208 
which inherits all of the data members and member functions defined 
by the message bin class 700. It further defines data members and 
member functions related to protocols for retrieving the message from a 
message source object instantiated from the message source class 704. 
15 Further, a message receiver class 708 may be provided 1208 which 

inherits all of the data members and member functions defined by the 
message source class 704. It further defines data members and member 
functions related to protocols for receiving the message at a receiver 
address from the messaging service and providing the message to the 
client application. Alternatively, a message iterator class 710 may be 
provided 1208 which has data members and member functions related 
to iteration functionality over a collection of messages from a message 
source object instantiated from the message source class 704. 

A file system message store name class 714 may be provided 1208 
which inherits all of the data members and member functions defined 
by the message bin name class 716. It further defines data members and 
member functions related to identifying a file system message store 
object instantiated from the file system message store class 714. 

A MessageReceiverAddress class 718 may be provided 1208 which 
inherits ail of the data members and member functions defined by the 
message bin name class 716. It further defines data members and 
member functions related to identifying a message receiver object 
instantiated from the message receiver class 708. Also, a internet 
receiver address class 722 may be provided 1208 which inherits all of the 
35 data members and member functions defined by the 

MessageReceiverAddress class 718. It further defines data members and 
member functions related to identifying an RFC -822 compliant Internet 
mailbox address. 
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This messaging interface process may be implemented in a 
computer system bv storing the classes in a storage device 120 and using 
a processor 110 in conjunction with RAM 114 and /or ROM to generate 
objects from the stored classes. A communications adapter 134 mav 
5 communicate a message object, instantiated from the message class 724, 
between the computer system and other computer svstems operativelv 
coupled together on a communication network. 

In addition, a program storage device may be created which is 
readable by a computer system tangibly embodying a program of 

10 instructions executable by the computer system. This program of 

instructions would perform one or more parts of the object oriented 
programming based messaging interface method described about. 

It is to be understood that even though numerous characteristics 
and advantages of various embodiments of the present invention have 

15 been set forth in the foregoing description, together with details of the 
structure and function of various embodiments of the invention, this 
disclosure is illustrative only, and changes may be made in detail, 
especially in matters of structure and arrangement of parts within the 
principles of the present invention to the full extent indicated bv the 

20 broad general meaning of the terms in which the appended claims are 
expressed. For example, the actual names or division or functions may 
be changed between the OOP classes and objects, detailed above, while 
maintaining substantially the same functionality without departing 
from the scope and spirit of the present invention. 
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Claims 



What is claimed is: 



5 1. An object oriented programming (OOP) based messaging 

interface method for use between a client application and a 
messaging service on a computer system, comprising the steps of: 
(a) providing a message class which has data members and 
member functions related to a message in the messaging 
10 service; 

rt» providing a message bin class which has data members and 
member functions related to holding the message; 

(c) providing a message bin name class which has data 

members and member functions related to identifying a 

13 message bin object instantiated from the message bin class; 

and 

(d) generating a messaging interface object for the message as 
an instance of one of the provided classes, the messaging 
interface object furnishing the client application with 
protocol independent access to the messaging service. 

1. The messaging interface method of claim 1 further comprising 
the step or providing a message address bundle class which has 
data members and member functions related to a message 
receiver address to which the message can be sent in the 
messaging service and related attributes of the message receiver 
address. 

The messaging interface method of claim 1 further comprising 
the step of providing a message address iterator class which has 
data members and member functions related to an iterator over 
the addresses. 
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The messaging interface method or claim 1 further comprising 
the step of providing a message reference class which inherits all 
of the data members and member functions defined bv the 
message class and further defines data members and member 
functions related to locking the message such that the message 
can not be modified. 



5. The messaging interface method of claim 1 further comprising 
the step of providing a drart message class which inherits all of 

10 the data members and member functions defined by the message 

class and further defines data members and member functions 
reiated to data integrity and interoperability of the message. 

6. The messaging interface method of ciaim 5 further comprising 
15 the ste P oi providing an OOP-specific message class which 

inherits all of the data members and member functions defined 
by the draft message class and further defines data members and 
member functions related to guaranteeing data integrity when 
delivering the message to an OOP-based message svstem. 
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7. The messaging interface method of claim 5 further comprising 
the step of providing an interoperable message class which 
inherits all of the data members and member functions defined 
bv the draft message class and further defines data members and 
member functions related to guaranteeing data interoperabilitv 
when delivering the message to a non-OOP-based message 
system. 

8. The messaging interface method of claim 1 further comprising 
the step of providing a message store class which inherits all of 
the data members and member functions defined by the message 
bin class and further defines data members and member 
functions related to protocols for storing the message into a 
message store object instantiated from the message store class. 
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The messaging interface method of claim 8 further comprising 
the step of providing a message sender class which inherits all of 
the data members and member functions defined bv the message 
store class and further defines data members and member 
functions related to protocols for submitting and sending the 
message from the client application to the messaging service. 

The messaging interface method of claim 9 further comprising 
the steps of: 

(a) providing a message source class which inherits all of the 
data members and member functions defined bv the 
message bin class and further defines data members and 
member functions related to protocols for retrieving the 
message from a message source object instantiated from 
the message source class; and 

(b) providing a file system message store class which inherits 
all of the data members and member functions defined bv 
the message sender class and the message source class and 
further defines data members and member functions 
related to protocols for storing, accessing and sending the 
message where the message is stored in a file system 
directory in a storage of the computer system. 

The messaging interface method of claim i further comprising 
the step or providing a message source ciass which inherits all of 
the data members and member functions defined bv the message 
bin class and further defines data members and member 
functions related to protocols for retrieving the message from a 
message source object instantiated from the message source class. 

The messaging interface method of claim 11 further comprising 
the step of providing a message receiver class which inherits all 
of the data members and member functions defined bv the 
message source ciass and further defines data members and 
member functions related to protocols for receiving the message 
at a receiver address from the messaging service and providing 
the message to the client application. 
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13. The messaging interface method of claim 11 further comprising 
the step of providing a message iterator class which has data 
members and member functions related to iteration functionality 
over a collection of messages from a message source object 

5 instantiated from the message source class. 

14. The messaging interface method of claim 10 further comprising 
the step of providing a file system message store name class 
which inherits all of the data members and member functions 

0 defined by the message bin name class and further defines data 

members and member functions related to identifving a file 
system message store object instantiated from the file system 
message store class. 

5 15. The messaging interlace method or claim 12 further comprising 
the step of providing a message receiver address class which 
inherits all of the data members and member functions defined 
by the message bin name class and further defines data members 
and member functions related to identifving a message receiver 

0 object instantiated from the message receiver class. 

16. The messaging interface method of claim 15 further comprising 
the step of providing a internet receiver address class which 
inherits all of the data members and member functions defined 
by the message receiver address class and further defines data 
members and member functions related to identifying an RFC- 
822 compliant Internet mailbox address. 
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A program storage dev.ce readable bv a computer svstem tangibly 
embodying a program of instructions executable bv the computer 
system to perform an object onented programming (OOP) based 
messaging interface method for use between a client application 
and a messaging service on the computer system, the method 
comprising the steps of: 

fa) providing a message class which has data members and 
member functions related to a message in the messaging 



service; 

10 (b) 



providing a message bin class which has data members and 
member functions related to holding the message; 
(c) providing a message bin name class which has data 

members and member functions related to identifying a 
message bin object instantiated from the message bin class; 
and 

fd) generating a messaging interface object for the message as 
an instance of one of the provided classes, the messaging 
interface object furnishing the client application with 
protocol independent access to the messaging service. 

The program storage device of claim 17 wherein the method 
further comprises the step of providing a message address bundle 
class which has data members and member functions related to a 
message receiver address to which the message can be sent in the 
messaging service and related attributes of the message receiver 
address. 

The program storage device of claim 17 wherein the method 
further comprises the step of providing a message address iterator 
class which has data members and member functions related to 
an iterator over the addresses. 

The program storage device of claim 17 wherein the method 
further comprises the step of providing a message reference class 
which inherits all of the data members and member functions 
defined by the message class and further defines data members 
and member functions related to locking the message such that 
the message can not be modified. 



SUBSTITUTE SHEET (RULE 26) 

BNSDOCID: <WO .. 9722928A1 P > 



WO 97/22928 



PCT/US96/20536 



10 



-55- 

21. The program storage device of ciaim 17 wherein the method 
further comprises the step of providing a draft message class 
which inherits ali of the data members and member functions 
defined by the message class and further defines data members 
and member functions related to data integritv and 
interoperability of the message. 

22. The program storage device of claim 21 wherein the method 
further comprises the step of providing an OOP-specific message 
class which inherits all of the data members and member 
functions defined by the draft message class and further defines 
data members and member functions related to guaranteeing 
data integrity when delivering the message to an OOP-based 

15 message system. 

23. The program storage device of claim 21 wherein the method 
further comprises the step of providing an interoperable message 
class which inherits all of the data members and member 

20 functions defined by the draft message class and further defines 

data members and member functions related to guaranteeing 
data interoperability when delivering the message to a non-OOP- 
based message system. 

25 24. The program storage device of claim 17 wherein the method 
further comprises the step of providing a message store class 
which inherits all of the data members and member functions 
defined by the message bin class and further defines data 
members and member functions related to protocols for storing 

30 the message into a message store object instantiated from the 

message store class. 
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25. The program storage device or claim 24 wherein the method 
further comprises the step of providing a message sender class 
which inherits all of the data members and member functions 
defined by the message store class and further defines data 

5 members and member functions related to protocols for 

submitting and sending the message from the client application 
to the messaging service. 

26. The program storage device of claim 25 wherein the method 
10 further comprises the steps of: 

(a) providing a message source class which inherits all of the 
data members and member functions defined by the 
message bin class and further defines data members and 
member functions related to protocols for retrieving the 
message from a message source object instantiated from 
the message source ciass; and 

(b) providing a file system message store class which inherits 
all of the data members and member functions defined by 
the message sender class and the message source class and 
further defines data members and member functions 
related to protocols for storing, accessing and sending the 
message where the message is stored in a file system 
directory in a storage of the computer system. 



15 



20 



25 



30 



The program storage device of claim 17 wherein the method 
further comprises the step of providing a message source class 
which inherits all of the data members and member functions 
defined by the message bin class and further defines data 
members and member functions related to protocols for 
retrieving the message from a message source object instantiated 
from the message source class. 
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The program storage device of claim 27 wherein the method 
further comprises the step of providing a message receiver class 
which inherits all of the data members and member functions 
defined by the message source class and further defines data 
members and member functions related to protocols for 
receiving the message at a receiver address from the messaging 
service and providing the message to the client application. 

The program storage' device of claim 27 wherein the method 
further comprises the step of providing a message iterator class 
which has data members and member functions related to 
iteration functionality over a collection of messages from a 
message source object instantiated from the message source class. 

The program storage device of claim 26 wherein the method 
further comprises the step of providing a file system message 
store name class which inherits all of the data members and 
member functions defined by the message bin name class and 
further defines data members and member functions related to 
identifying a file system message store object instantiated from 
the file system message store class. 

The program storage device of claim 2S wherein the method 
rurther comprises the step of providing a message receiver 
address class which inherits all of the data members and member 
functions defined bv the message bin name class and further 
defines data members and member functions related to 
identifying a message receiver object instantiated from the 
message receiver class. 

The program storage device of claim 31 wherein the method 
further comprises the step of providing a internet receiver 
address class which inherits all of the data members and member 
functions defined by the message receiver address class and 
further defines data members and member functions related to 
identifying an RFC-S22 compliant Internet mailbox address. 
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An object oriented programming (OOP) based messaging 
interface between a client application and a messaging service for 
a computer system, comprising: 

(a) a storage device, in the computer system, which stores 
OOP-based classes, the classes, including: 

(i) a message class which has data members and 
member functions related to a message in the 
messaging service; 

(ii) a message bin class which has data members and 
member functions related to holding the message; 
and 

(iii) a message bin name class which has data members 
and member functions related to identifying a 
message bin object instantiated from the message 
bin ciass; and 

a processor, operativeiv coupled to the storage device, 
which generates a messaging interface object for the 
message as an instance of a class stored in the storage 
device, the messaging interface object furnishing the client 
application with protocol independent access to the 
messaging service. 



20 



34. 



30 



3D. 



(b) 



35 



The messaging interface of claim 33 further comprising a 
communication adapter, operativeiv coupled to the processor, 
which communicates a message object, instantiated from the 
message class, between the computer system and other computer 
systems operativeiv coupled together on a communication 
network. 

The messaging interface of claim 33 wherein the storage device 
further includes a message address bundle class which has data 
members and member functions related to a message receiver 
address to which the message can be sent in the messaging 
service and related attributes of the message receiver address. 



SUBSTITUTE SHEET (RULE 26) 



WO 97/22928 



PCTAJS96/20536 



-59- 

36. The messaging interface of claim 33 wherein the storage device 
further includes a message address iterator class which has data 
members and member functions related to an iterator over the 
addresses. 

5 

37. The messaging interface of claim 33 wherein the storage device 
further includes a message reference class which inherits all of 
the data members and member functions defined by the message 
class and further defines data members and member functions 

10 related to locking the message such that the message can not be 

modified. 

38. The messaging interface of claim 33 wherein the storage device 
turther includes a draft message class which inherits all of the 

15 data members and member functions defined by the message 

class and further defines data members and member functions 
related to data integrity and interoperability of the message. 

39. The messaging interface of claim 38 wherein the storage device 
20 further includes an OOP-specific message class which inherits all 

of the data members and member functions defined bv the draft 
message class and further defines data members and member 
functions related to guaranteeing data integrity when delivering 
the message to an OOP-based message svstem. 

25 

40. The messaging interface of claim 38 wherein the storage device 
further includes an interoperable message class which inherits all 
of the data members and member functions defined by the draft 
message class and further defines data members and member 

30 functions related to guaranteeing data interoperability when 

delivering the message to a non-OOP-based message system. 

41. The messaging interface of claim 33 wherein the storage device 
further includes a message store class which inherits all of the 

35 data members and member functions defined by the message bin 

class and further defines data members and member functions 
related to protocols for storing the message into a message store 
object instantiated from the message store class. 
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The messaging interface or claim 41 wherein the storage device 
further includes a message sender class which inherits all of the 
data members and member functions defined by the message 
store class and further defines data members and member 
functions related to protocols for submitting and sending the 
message from the client application to the messaging service. 

The messaging interface of claim 42 wherein: 

(a) the storage device further includes a message source class 
which inherits all of the data members and member 
functions defined by the message bin class and further 
defines data members and member functions related to 
protocols for retrieving the message from a message source 
obiect instantiated from the message source class: and 

(b) the storage device further includes a file system message 
store class which inherits all. of the data members and 
member functions defined by the message sender class and 
the message source class and further defines data members 
and member functions related to protocols for storing, 
accessing and sending the message where the message is 
stored in a file system directory in a storage of the 
computer system. 



The messaging interface of claim 33 wherein the storage device 
further includes a message source class which inherits all of the 
data members and member functions defined by the message bin 
class and further defines data members and member functions 
related to protocols for retrieving the message from a message 
source object instantiated from the message source class. 

The messaging interface of claim 44 wherein the storage device 
further includes a message receiver class which inherits all of the 
data members and member functions defined bv the message 
source class and further defines data members and member 
functions related to protocols for receiving the message at a 
receiver address from the messaging service and providing the 
message to the client application. 
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The messaging interface of claim 44 wherein the storage device 
further includes a message iterator class which has data members 
and member functions related to iteration functionality over a 
collection of messages from a message source object instantiated 
from the message source ciass. 

The messaging interface of claim 43 wherein the storage device 
further includes a file system message store name class which 
inherits all of the data members and member functions defined 
by the message bin name class and further defines data members 
and member functions related to identifying a file system 
message store object instantiated from the file system message 
store class. 

The messaging interface of claim 45 wherein the storage device 
further includes a message receiver address class which inherits 
all of the data members and member functions defined by the 
message bin name class and further defines data members and 
member functions related to identifying a message receiver object 
instantiated from the message receiver class. 

The messaging interface of claim 48 wherein the storage device 
further includes a internet receiver address class which inherits 
all or the data members and member runctions defined bv the 
message receiver address class and further defines data members 
and member functions related to identifying an RFC-822 
compliant Internet mailbox address. 
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